Billig, database

Billig-databasen er ikke strengt tatt en separat database, men et eget skjema i MDB2 (se MedlemsDB2), nærmere bestemt skjemaet «billig». Dette er gjort slik ettersom man trenger et par fremmednøkler og views mot MDB2-dataene (nærmere bestemt: ordre kan eies av MDB2-brukere, og det er relevant å hente ut kortinformasjon for disse), og slike er svært hårete å få gjort på tvers av databaser. Utover dette er det ikke spesielt mange koblinger mellom dem.

Merk at Billig-databasen har engelske tabell- og feltnavn, noe som er konsistent med Billig-koden – MDB2 er av historiske årsaker på norsk (unntatt koden, som er på engelsk...).

Det finnes også en lokal database på hver dørklient; denne er beskrevet i Billig dør.

Generelt

Databasen realiserer strukturen som er beskrevet i Billig generelt, dvs. arrangement -> billettgruppe -> prisgruppe -> billett. Utover det er det noen få tabeller relatert til utskrift (se Billig utskrift) og en tabell som holder den gjeldende HMAC-nøkkelen (ettersom noen funksjoner, som create_purchase(), trenger å kunne beregne HMACer; se under). Det finnes et UML-diagram av hele MDB2 pluss Billig; en halvveis oppdatert versjon skal henge på døren til serverrommet.

Det er viktig å merke seg forskjellen mellom prisgrupper og billettgrupper. Prisgrupper deler antall billetter med andre prisgrupper i samme billettgruppe; dersom det på UKErevyen (et arrangement) er utsolgt for sitteplasser (en billettgruppe på UKErevyen) er det utsolgt uansett om du er medlem (en prisgruppe av sitteplasser) eller ikke-medlem (en annen prisgruppe av sitteplasser), men det kan godt være igjen flere billetter i billettgruppen ståplasser.

Billettlåsing

Databasen er overveiende i tredje normalform (3NF), med ett unntak: Hver billettgruppe har i tillegg til et felt som sier hvor mange billetter som finnes totalt, et felt som sier hvor mange billetter som er allerede solgt (og ikke refundert). Dette er strengt tatt duplisering av informasjon (og 3NF-brudd), men det har en praktisk årsak: Vi er nødt til å kunne garantere at man aldri selger flere billetter enn den gitte grensen. Derfor setter man en lås på den aktuelle raden når man skal bestille billetter, hvilket sørger for at bare én transaksjon kan bestille billetter innenfor samme billettgruppe samtidig, og dermed at man ikke kan få en racecondition slik at to transaksjoner som kjører samtidig sammen kan gå over grensen. (Noen databaser støtter det som kalles predikatlåser, der man kan si «lås for alle rader i billett-tabellen som har prisgruppe satt til en gitt verdi», men PostgreSQL støtter ikke dette, og det krever mer kompleksitet og en litt annen normalisering enn den vi har brukt. Alternativt kunne man låst hele billett-tabellen, men dette gir håpløs ytelse når mye skal skje samtidig.)

Nyttefunksjoner

For å garantere at prosedyren over blir fulgt, med rett låsing (SELECT ... FOR UPDATE) av riktige rader osv., har man laget en SQL-funksjon som heter create_purchase(). Alt billettsalg gjøres via denne, og den sørger for en relativt utfyllende mengde konsistenssjekker og låsing, men den tillater også en del overstyring (som f.eks. å tillate salg av billetter til et arrangement selv om man egentlig ikke er innenfor salgsperioden). www.samfundet.no (se Billig dave) har tilgang til en begrenset versjon av denne, som ikke kan overstyre noe – den kjører i tillegg med «SECURITY DEFINER», slik at den kjører som en administratorbruker. På denne måten kan ikke LIM-web-brukeren tukle med billett-tabellene direkte, kun via funksjonen. Dette sikrer konsistent, øker forhåpentligvis sikkerheten og reduserer muligheten for bugs. Det er tenkt at om f.eks. UKA ønsker å selge billetter via Billig, vil de få tilsvarende tilgang til denne funksjonen-

Det finnes en del andre nyttefunksjoner (f.eks. beregning av HMAC, eller konsistent datoformatering), men disse er primært til internt bruk i koden.

Brukere og tilganger

Tilgangene på SQL-nivå er gitt etter prinsippet om minimumstilgang. Alle tilganger til MDB2 (med unntak av noen ytterst få for billig.samfundet.no-brukeren) er abstrahert bort i views, og brukere har ellers fått tilgang til utelukkende de operasjoner de trenger. Følgende brukere finnes, hvert tilhørende sitt grensesnitt:

billig_web (for billig.samfundet.no, se Billig web): Nesten full tilgang til det meste i billig-skjemaet, og noen få tilganger i public-skjemaet (MDB2).
billig_limweb (for www.samfundet.no, se Billig dave): SELECT-rettigheter på en del tabeller i billig-skjemaet, samt kjørerettigheter på en begrenset versjon (uten overstyring) av create_purchase(). (Merk: Når UKA kommer, burde de antageligvis få en separat bruker, og disse tilgangene burde gis til en rolle både billig_limweb og billig_ukeweb er medlem av, slik at man slipper å duplisere tilganger.)
billig_door (for dørmigreringen, se Billig dør): SELECT på hendelser og et eget migreringsview, UPDATE på billetter (for å kunne sette dem brukt).
billig_print (for utskriftsklienten, se Billig utskrift): SELECT på skrivere, fulle rettigheter på utskriftskøene.

Lenker: Start, billig, billig dave, billig frontend-api, billig generelt, billig paynet, billig stripe